git format-patch 用法【转】

本文转载自：http://blog.csdn.net/xzongyuan/article/details/9425739

git format-patch相对于git diff更便于操作，是更新的打包方式，应该采取这种打包方式。git diff打包的patch只能使用git apply处理。而git format-patch的补丁，可以应当使用git am命令。

基本用法

git format-patch xxxx.patch

 

第一种 

format-patch可以基于分支进行打包，也可以基于上几次更新内容打包。

 

基于上几次内容打包

git format-patch HEAD^  有几个^就会打几个patch，从最近一次打起

git format-patch HEAD^^ 最近的二个patch内容

以下代码作用同上

git format-patch -1 

git format-patch -2

 

git format-patch -1 -4    //可以打包版本2,3的patch。但是发现有时候会把最近4个包都打包出来，具体原因未知。

参考：http://leave001.blog.163.com/blog/static/16269129320126944238969/

关于分支，可以参考：http://www.cnblogs.com/y041039/articles/2411600.html

 

第二种

git format-patch -M origin/master

format-patch 命令依次创建补丁文件,并输出文件名。上面的 -M 选项允许 Git 检查是
否有对文件重命名的提交。我们来看看补丁文件的内容:

[cpp] view plain copy
 
  1. $ cat 0001-add-limit-to-log-function.patch  
  2. From 330090432754092d704da8e76ca5c05c198e71a8 Mon Sep 17 00:00:00 2001  
  3. From: Jessica Smith <jessica@example.com>  
  4. Date: Sun, 6 Apr 2008 10:17:23 -0700  
  5. Subject: [PATCH 1/2] add limit to log function  
  6. Limit log functionality to the first 20  
  7. ---  
  8. lib/simplegit.rb |  
  9. 2 +-  
  10. 1 files changed, 1 insertions(+), 1 deletions(-)  
  11. diff --git a/lib/simplegit.rb b/lib/simplegit.rb  
  12. index 76f47bc..f9815f1 100644  
  13. --- a/lib/simplegit.rb  
  14. +++ b/lib/simplegit.rb  
  15. @@ -14,7 +14,7 @@ class SimpleGit  
  16. end  
  17. def log(treeish = 'master')  
  18. -  
  19. +  
  20. command("git log #{treeish}")  
  21. command("git log -n 20 #{treeish}")  
  22. end  
  23. def ls_tree(treeish = 'master')  
  24. --  
  25. 1.6.2.rc1.20.g8c5b.dirty  



如果有额外信息需要补充,但又不想放在提交消息中说明,可以编辑这些补丁文件,
在第一个 --- 行之前添加说明,但不要修改下面的补丁正文,比如例子中的 Limit log
functionality to the first 20 部分。这样,其它开发者能阅读,但在采纳补丁时不会将
此合并进来。

应用patch

[cpp] view plain copy
 
  1. $ git am 0001-limit-log-function.patch  
  2. Applying: add limit to log function  


你会看到它被干净地应用到本地分支,并自动创建了新的提交对象。

有时,我们也会遇到打不上补丁的情况。这多半是因为主干分支和补丁的基础分支相差太远,但也可能是因为某些依赖补丁还未应用。这种情况下,git am 会报错并询问该怎么
做:

[cpp] view plain copy
 
  1. $ git am 0001-seeing-if-this-helps-the-gem.patch  
  2. Applying: seeing if this helps the gem  
  3. error: patch failed: ticgit.gemspec:1  
  4. error: ticgit.gemspec: patch does not apply  
  5. Patch failed at 0001.  
  6. When you have resolved this problem run "git am --resolved".  
  7. If you would prefer to skip this patch, instead run "git am --skip".  
  8. To restore the original branch and stop patching run "git am --abort".  


Git 会在有冲突的文件里加入冲突解决标记,这同合并或衍合操作一样。解决的办法也一样,先编辑文件消除冲突,然后暂存文件,最后运行 git am --resolved 提交修正结果

[cpp] view plain copy
 
  1. $ (fix the file)  
  2. $ git add ticgit.gemspec  
  3. $ git am --resolved  
  4. Applying: seeing if this helps the gem  

如果想让 Git 更智能地处理冲突,可以用 -3 选项进行三方合并。如果当前分支未包含该补丁的基础代码或其祖先,那么三方合并就会失败,所以该选项默认为关闭状态。一般来
说,如果该补丁是基于某个公开的提交制作而成的话,你总是可以通过同步来获取这个共同祖先,所以用三方合并选项可以解决很多麻烦:

[cpp] view plain copy
 
  1. $ git am -3 0001-seeing-if-this-helps-the-gem.patch  
  2. Applying: seeing if this helps the gem  
  3. error: patch failed: ticgit.gemspec:1  
  4. error: ticgit.gemspec: patch does not apply  
  5. Using index info to reconstruct a base tree...  
  6. Falling back to patching base and 3-way merge...  
  7. No changes -- Patch already applied.  


像上面的例子,对于打过的补丁我又再打一遍,自然会产生冲突,但因为加上了 -3 选项,所以它很聪明地告诉我,无需更新,原有的补丁已经应用。
对于一次应用多个补丁时所用的 mbox 格式文件,可以用 am 命令的交互模式选项 -i,这样就会在打每个补丁前停住,询问该如何操作:

[cpp] view plain copy
 
  1. $ git am -3 -i mbox  
  2. Commit Body is:  
  3. --------------------------  
  4. seeing if this helps the gem  
  5. --------------------------  
  6. Apply? [y]es/[n]o/[e]dit/[v]iew patch/[a]ccept all  


在多个补丁要打的情况下,这是个非常好的办法,一方面可以预览下补丁内容,同时也可以有选择性的接纳或跳过某些补丁。
打完所有补丁后,如果测试下来新特性可以正常工作,那就可以安心地将当前特性分支合并到长期分支中去了

posted @ 2017-10-19 17:48  请给我倒杯茶  阅读(13473)  评论(0)  编辑  收藏  举报